Date: Fri, 17 Jun 94 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #121 To: tcp-group-digest TCP-Group Digest Fri, 17 Jun 94 Volume 94 : Issue 121 Today's Topics: Calling John Ackerman AG9V Standard Digital Radio Interface Proposal (4 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Thu, 16 Jun 1994 22:27:23 -0500 (CDT) From: Kurt Freiberger Subject: Calling John Ackerman AG9V To: tcp-group@ucsd.edu (TCP-Group Mailing List) John, please send me your email address. I have some radio questions for you. We now return you to the scheduled pogrom... kf -- # Kurt Freiberger, WB5BBW Dept. of Computer Science, TAMU # # Internet: kurt@cs.tamu.edu | "Even MY hypocrisy has its limits." # # AuralNet: 409/847-8607 | # # AMPRNet: wb5bbw@wb5bbw.ampr.org | - "Doc" Holliday, Tombstone # # Disclaimer: Not EVEN an official document of Texas A&M University # ------------------------------ Date: Thu, 16 Jun 94 13:16:35 +0100 From: agodwin@acorn.co.uk (Adrian Godwin) Subject: Standard Digital Radio Interface Proposal To: net_sig@tcet.unt.edu, tcp-group@UCSD.EDU > > A Proposal for a Standard Digital Radio Interface > > (stuff deleted) > > Requirements > > The requirements of the interface are as follows: > - connect any DR to any TNC; > - be transparent to the data stream; > - operate over a wide range of speeds; > - operate with both synchronous and asynchronous modulation modes; > - operate in both full- and half-duplex modes as well as in transmit- > only and receive-only systems; > - provide good immunity to electromagnetic interference (EMI); > - be tolerant of variations in the equipment: not require any > adjustments when equipment is changed; > - operate over cable distances from zero to at least 10 meters; > - be usable for all existing digital communications modes and for all > anticipated modes in the future; > - operate at all existing speeds and at all reasonable future speeds, > at least up to 2 Mb/s; > - have a single standardized connector so that connection is "plug and > play;" > - sense when cable is disconnected or when the DR is powered down; > - make use of existing standards, where possible; and > - allow easy migration from the current system. > Seems a good start, and the presented solution addresses it well. However, the suggestion is extremely similar to that provided by a synchronous half-duplex mode (except for the differental-mode signals, which are welcome). I believe suggestions made for clock source etc. to be correct, unlike the RUH modem which requires the TNC to source a clock. The clock edge on which data is valid (and the timing) must be specified! However, modem interfaces have had a problem in recent years - they don't allow for an intelligent interface. The result is the Hayes and V25.bis protocols, which suffer severely from being in-band to the communications channel. The disadvantages of this are : - can't control the modem/radio without interrupting the data stream - the controller in the radio may be pretty dumb, yet have to talk at the data rate used by the comms channel - changeover from data to control requires extra control lines or (worse) in-band escape sequences. In order to avoid this problem, I'd suggest adding to the spec an optional control interface and accompanying protocol. Obvious uses for this are channel change, carrier level measurement, power control and controlling a CW ident. I think it has to be optional to allow for present radio/modem designs, but the implementation used when no interface exists should be specified - perhaps looped back if a TXD/RXD pair is used, or shorted to ground if an IIC-like bus is used. Both the TNC and the radio should operate in a reasonable manner if the other device doesn't implement the control interface. A clock-and-data interface is attractive for use with small microcontrollers as might typically be used in an intelligent radio-modem, since this can simplify the software implementing a software USART. IIC is a possibility, but the electrical interface is less robust than the rest of the spce and there are copyright constraints on the standard (must use a Philips- licensed component to implement part of the system). It might be useful to ensure that the control protocol can be implemented using 'spare' parts of typical high-speed comms controllers - bit-banging I/O lines, SPI ports etc. > > The physical connector selected is a high-density 15-pin D-series > connector. This connector is small enough to be used on mobile and > portable equipment and yet it reasonably rugged, reliable and > inexpensive. The male connector (plug) is used on the TNC and the > female connector (socket) is used on the DR. Although the same type of I admit to a prejudice against these connectors. Because of their high density, they tend to use formed pins rather than turned pins - I find the former less robust and inclined to bend. In addition, PCB-mount male connectors seem to be much less available than PCB-mount female connectors. This may be because many vendors only sell the parts required for PCs (female PCB connectors and male cable connectors), though there seems to be less of a problem getting cable-mount females. > equipment together. It provides a simple, inexpensive, versatile, and > easy-to-use solution. It is applicable to all current packet radio > systems, as well a other digital systems and it does not inhibit future > improvements to packet radio systems, either in the modulation and > coding techniques or in the protocols. While the exact specifications > remain to be finished and tested through implementation, much existing > technology is being used and no problems are anticipated. The author > welcomes suggestions for the improvement of this interface and is > interested in hearing from a few persons who are willing to design and > test interfaces for various modems and TNCs. > I'd certainly benefit from a standard interface and would be happy to work on it in my copious spare time. I think you need to present a complete, costed design - I think the manufacturers of TNCs and modems might argue with you about how inexpensive this interface is when compared to a Molex header and a few TTL signals. But it's still the right thing to aim for! -adrian ------------------------------ Date: Thu, 16 Jun 1994 16:31:06 -0700 From: brian@nothing.ucsd.edu (Brian Kantor) Subject: Standard Digital Radio Interface Proposal To: tcp-group@ucsd.edu I'd really recommend the use of RS-485 and RS-530 instead of once again creating our own unique-to-ham-radio incompatable-with-the-world interface. What we're talking about here is just a radio modem. It's no different from a wireline, optical, or other modem as far as its interface needs; we can (and SHOULD) use established standards wherever we can. The ones mentioned above aren't even a bad fit. - Brian ------------------------------ Date: Thu, 16 Jun 1994 23:45:33 -0400 From: "Louis A. Mamakos" Subject: Standard Digital Radio Interface Proposal To: tcp-group@UCSD.EDU > I'd really recommend the use of RS-485 and RS-530 instead of once again > creating our own unique-to-ham-radio incompatable-with-the-world > interface. > > What we're talking about here is just a radio modem. It's no different > from a wireline, optical, or other modem as far as its interface needs; > we can (and SHOULD) use established standards wherever we can. The ones > mentioned above aren't even a bad fit. If we really wanted to push the state-of-the-art (Ha!), why not define the interface as ethernet, which will be plenty fast enough. Boards for PeeCee boxes are less than $100, and you can hang a bunch of "things" on an ethernet segment. You need only define a protocol to run over the net to carry frames of stuff between the various devices. If you were *really* clever, you could also transport PCM audio this way too. Clever folks could develop a small single board computer to terminate the ethernet in a device, and which contains a simple ROM-based software module to do generic sorts of things. Hook it (or build it into) things like radios, rotator boxes, etc. Wouldn't it be cool of the front panel of your radios was "soft", and you had a single (ethernet) coax running from the operating position, out to the antennas where the actual RF hardware is. Heck, if you didn't want to use ethernet because it's too "hard", look at the more expensive and slower ISDN hardware devices. If nothing new or interesting is going to be done, just stick with RS232 and a DB9 connector. Louis A. Mamakos, WA3YMH louie@alter.net UUNET Technologies, Inc. uunet!louie 3110 Fairview Park Dr., Suite 570 Voice +1 703 204 8023 Falls Church, Va 22042 Fax +1 703 204 8001 ------------------------------ Date: Fri, 17 Jun 94 00:07 EDT From: nelson@crynwr.com (Russell Nelson) Subject: Standard Digital Radio Interface Proposal To: louie@alter.net From: "Louis A. Mamakos" Date: Thu, 16 Jun 1994 23:45:33 -0400 Clever folks could develop a small single board computer to terminate the ethernet in a device, and which contains a simple ROM-based software module to do generic sorts of things. Hook it (or build it into) things like radios, rotator boxes, etc. Yes! Yes! Yes! Sixteen bits of digital I/O, and a sixteen bit D/A and A/D would be enough for many purposes. Or maybe a daughter board that implements the I/O? -russ ftp.msen.com:pub/vendor/crynwr/crynwr.wav Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | Quakers do it in the light Potsdam, NY 13676 | LPF member - ask me about the harm software patents do. ------------------------------ End of TCP-Group Digest V94 #121 ******************************